The generated PodDisruptionBudget set maxUnavailable = (voters-1)/2 over
the role=voter pods. That form re-bases under churn: the disruption
controller computes allowed = currentHealthy - (expectedCount -
maxUnavailable), and expectedCount is derived from the EtcdMember /scale
subresources of the currently-matching pods. During a node rotation each
removed member shrank expectedCount, refilling the budget mid-drain — a
3-of-5 production cluster was legally evicted down to 2-of-2 quorum for
~36 minutes (2026-07-30 incident).

An integer minAvailable has no expectedCount term (allowed =
currentHealthy - minAvailable), so the floor cannot move as membership
shrinks. The floor is the quorum (n/2+1) of max(live voters,
status.observed.replicas):

  - Steady state: identical disruptions to the old budget, since
    n - (n-1)/2 = n/2 + 1.
  - Unplanned churn: the latched target holds the floor at steady-state
    quorum while the operator refills membership; this would have
    clamped the incident.
  - Intentional scale-down: the live count dominates and steps the
    floor down as members are removed via MemberRemove (not the
    eviction API), so a 5->3 shrink never wedges drains.
  - Bootstrap/scale-up: the target dominates and voter evictions block
    until the cluster reaches size; learners are outside the selector
    and unaffected.

The update path now also migrates PDBs left by previous versions:
maxUnavailable is cleared in the same patch that sets minAvailable
(a PDB with both fields is invalid). Delete-at-zero-voters, the
role=voter selector, and additionalMetadata merging are unchanged;
no API surface is added.

The EtcdMember /scale contract also stays, but its comments are
corrected: they claimed the PDB controller requires /scale and goes
SyncFailed without it, which is only true of maxUnavailable and
percentage minAvailable budgets — an integer minAvailable takes
expectedCount = len(selected pods) and never resolves scale. The
subresource is kept for any user-created budget over member Pods that
does resolve scale.

Signed-off-by: K.J. Valencik <kjvalencik@gmail.com>

Two descriptions of the new minAvailable budget were inaccurate.

The migration tool still told users their dropped
spec.podDisruptionBudgetTemplate would be replaced by a PDB with
maxUnavailable=(voters-1)/2, a shape the operator no longer emits.
Describe the emitted budget instead. The kitchen-sink warning
assertion matched only the "spec.podDisruptionBudgetTemplate" prefix,
so it passed against the stale text; it now pins the full sentence.

The docs claimed voter evictions "block entirely" while the cluster is
below target. Allowed disruptions are healthy - (target/2 + 1), so
being below target is not sufficient: at target 5 with 4 healthy
voters one eviction is still allowed, at target 7 with 6 healthy two
are. The claim holds only for a 3-member target, where any shortfall
does reach the floor. Reword concepts.md and operations.md to state
the actual condition — evictions block once healthy voters fall to
floor(target/2)+1 — and add table rows to TestPDBMinAvailable pinning
the anchors behind those numbers. README dropped the max(live, target)
half of the formula, which is the branch that keeps a 5->3 scale-down
from wedging drains; restore it.

Also rename the local min to minAvail in reconcilePDB so it stops
shadowing the builtin nine lines below a use of the builtin max.

No behaviour change: pdbMinAvailable and reconcilePDB are untouched
apart from the rename.

Assisted-By: Claude Opus 5
Signed-off-by: Timofei Larkin <lllamnyp@gmail.com>